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(54) Method and system for controlling certificate based open payment transactions 



(57) Methods and systems for controlling certificate- 
based open payment transactions involving a merchant 
and a customer utilizing various types of networks and 
terminals. Prior to accessing a merchant POS terminal 
or, for example, a merchant website, a customer obtains 
a certificate from a service provider (SP), such as a 
bank, certifying his identification (ID) and his relevant 
financial information, in a form that is understandable by 
the SP. The SP is capable of performing multiple func- 
tions. For example, the SP is capable of acting as a cer- 
tificate authority when it issues the customer's certifi- 
cates, an authenticator when it receives private-key en- 
crypted certificates from the customers to be decrypted 
using the corresponding public-key, and an authorizing 
authority when it checks the value available in a custom- 
er* chosen payment account against the requested pur- 
chase or transfer amount. 
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Description 

Background of the Invention 

[0001] With the current exponential growth in the 5 
number of Internet users conies an equal amount of 
growth in the number of buyers and sellers seeking to 
do electronic-type business. In accordance with the av- 
erage customer's expectation of having shopping at 
their fingertips, is the customer's equally high expecta- *0 
tion that payment should be quick and easy and ex- 
pense should be minimized. Unfortunately, the current 
methods of purchasing and paying for goods and/or 
services either, for example, over the Internet via point- 
of-service (POS) terminals, personal computers (PCs), * 5 
personal digital assistants (PDAs), set-top boxes or 
wireless devices, involve significant transaction costs. 
These transaction costs include fees paid by the mer- 
chant to credit verification companies and the risk of 
fraud, borne by both the merchant and customer when 20 
using current payment schemes. Consequently, a key 
issue that is currently driving the electronic commerce 
industry is security. 

[0002] A first conventional method of transacting busi- 
ness over the public networks involves a merchant, a 25 
customer, and an account servicer. In practicing this 
method, the account servicer provides hardware and/or 
software to the customer that includes credit or debit in- 
formation and a public key encryption file. The customer 
then may use the hardware or software, to make a pur- so 
chase over an unsecured network, such as the Internet. 
When the customer inserts the hardware into an appro- 
priate reader or runs the software, the customer's pur- 
chase information is encrypted with a public key from 
the public key file and is sent to the merchant. The mer- 35 
chant is not in possession of the private key and conse- 
quently, cannot read the encrypted file information, such 
as the customer's credit card number. The merchant 
then adds his own purchase information and forwards 
the entire encrypted message to the account servicer <o 
for authorization to proceed with the transaction. The ac- 
count servicer then decrypts the message with the ap- 
propriate private key and informs the merchant as to 
whether or not to proceed with the transaction. This 
method of transacting still uses the existing credit card <5 
verification infrastructure. 

[0003] A second conventional method of doing busi- 
ness between a customer and a merchant, whether from 
a POS terminal or from a PC, via the Internet, requires 
multiple parties including at least the merchant, a mer- 50 
chant acquirer, a credit card account issuer, a merchant 
bank and of course, the consumer. In some instances, 
another bank, a customer's bank, separate from the 
credit card account issuer, is also a party. In practicing 
this method, a customer would, for example, enter a 55 
website for a product that the customer wishes to pur- 
chase and enters name, address, product information, 
and credit card number and expiration. This information 



2 

will go through a merchant acquirer who the merchant 
pays to handle the authorization of credit card transac- 
tions. This merchant acquirer probably represents hun- 
dreds of merchants and handles all of their transactions 
by just sorting through the purchase requests from cus- 
tomers, finding which credit card issuers need to be con- 
tacted for authorization and performing the authoriza- 
tion. For example, there are a number of different credit 
cards available to consumers such as MasterCard ™ , Vi- 
sa™, Discover™, and Diners Club™, each one of which 
may require a separate line for authorization. The mer- 
chant acquirer gets paid by the merchant to handle all 
of the sorting and sending through the conventional 
credit authorization lines. After the credit card transac- 
tion is authorized, the merchant must further deal with 
the settlement network in order to actually see his ac- 
count credited while the credit card holder's account is 
debited. There are many transaction costs involved in 
this method of transacting electronically. Each of these 
transactions, in addition to the assumptions of liability, 
are reflected in the prices charged to customers. Fur- 
ther, there is still a security issue involved since there 
are multiple parties who are dealing with the customer's 
credit card information. 

[0004] A third method of making a purchase over a 
network involves the use of electronic funds transfer in- 
struments, commonly referred to as electronic checks. 
In practicing this method of transacting electronically us- 
ing electronic funds transfer instruments, the customer 
obtains software which allows him to create an electron- 
ic check either in response to the receipt of an authen- 
ticated payment request from a merchant or on his own 
volition. In all instances, the parties involved hold the 
necessary public keys to decrypt the private key en- 
crypted digital signatures and certificates of each of the 
other parties. So, when the customer sends the digitally 
signed electronic check to the merchant, along with a 
certificate issued by the customer's bank and appropri- 
ate account, the merchant utilizes a public key to decrypt 
the information. Once satisfied with the information, the 
merchant digitally endorses the electronic check and 
appends his own banking information to the check and 
deposits the check with his own bank. The merchant's 
bank must then institute conventional clearing proce- 
dures and eventually return the processed electronic 
check to the customer's bank, for further settlement pro- 
cedures on that end. In short, this method of electronic 
check payment, while adding an element of conven- 
ience, still requires the same clearing and settlement 
procedures as are necessary for the processing of "pa- 
per checks." Further, the customer's personal financial 
information is bounced around among a number of par- 
ties, along multiple private and public networks, the lat- 
ter being quite susceptible to "electronic break-ins" re- 
sulting in increased occurrences of fraud. 
[0005] it would be advantageous to minimize the 
transaction costs associated with current payment 
schemes and to limit the number of parties who are privy 
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to the personal financial information of the customer, as 
well as the merchant, during electronic transactions. 
The lowering of a merchant's costs of doing business 
will be reflected in the price charged to the customer for 
the desired goods and/or services. 

Summary of the Invention 

[0006] Generally, the preferred embodiments of the 
present invention comprise methods and systems for 
controlling certificate-based open payment transactions 
involving a merchant and a customer utilizing various 
types of networks and terminals. In the preferred em- 
bodiments, prior to accessing a merchant POS terminal 
or, for example, a merchant website, a customer obtains 
a certificate from a service provider (SP), such as a 
bank, certifying his identification (ID) and his relevant 
financial information, in a form that is understandable by 
the SP. The SP is capable of performing multiple func- 
tions. For example, the SP is capable of acting as a cer- 
tificate authority when it issues the customer's certifi- 
cates, an authenticator when it receives private-key en- 
crypted certificates from the customers to be decrypted 
using the corresponding public-key, and an authorizing 
authority when it checks the value available in a custom- 
er' chosen payment account against the requested pur- 
chase or transfer amount. In other examples, the SP 
does not perform the authorization but instead consults 
with an outside authorization authority (e.g., a custom- 
er's financial institution). 

[0007] In the following embodiments, the certificate is- 
sued by the SP is located on a piece of hardware, ge- 
nerically referred to as a smart card. When this certifi- 
cate is accessed by the customer at the POS terminal 
or through a PC, PDA or wireless device (e.g., tele- 
phone, set-top box) in response to a payment request 
by a participating merchant, the SP recognizes the in- 
formation originally certified by them as well as addition- 
al purchase information and merchant ID information. 
The SP then authenticates the certificate and merchant 
ID information (e.g., payment method and amount) and 
either performs the authorization itself or obtains author- 
ization from the appropriate financial institution and no- 
tifies the merchant that the payment amount will be de- 
posited into the merchant's specified account. The mer- 
chant is able to validate the SP's promise to pay and 
release the goods since the merchant possesses the 
SP's public key and is thus able to unlock messages 
from the SP that are signed with SP's private key. Addi- 
tionally, the certifying authority may request some form 
of merchant response to the notification prior to perform- 
ing the deposit. 

[0008] A first particular embodiment described in fur- 
ther detail below is a method for facilitating a financial 
transaction over a first network. The method includes 
issuing a programmable memory device to a first user. 
The programmable memory device contains at least the 
following for formulating payment instructions network 



address instructions for an issuer of the programmable 
memory device, a first user's digital certificate, a first us- 
er's financial account information, and an encryption 
program. The method also includes issuing software to 

5 a second user. The software includes payment informa- 
tion of the second user including a second user's finan- 
cial account information. The software is capable of in- 
teracting with the programmable memory device over 
the first network. A connection is formed between the 

10 programmable memory device and the software and the 
payment instructions are received via the connection. 
The second user's payment information is added to the 
payment instructions. The payment information and the 
payment instructions are routed to the issuer utilizing 

15 the network address instructions and the issuer is capa- 
ble of accessing at least one of the first user's financial 
account information and a second user's financial ac- 
count information. 

[0009] A second particular embodiment described in 
20 detail below is a system for facilitating financial transac- 
tions over a network. The system includes a program- 
mable memory device including at least an identifying 
certificate, payment information, network routing in- 
structions and an encryption program. The system fur- 
25 ther includes a first server for offering at least one prod- 
uct via the network through a terminal and a processor 
connected to the terminal. The processor is used for (a) 
accessing the programmable memory device.(b) re- 
trieving the identifying certificate, the payment informa- 
30 tion, the network routing instructions and the encryption 
program off of the programmable memory device, (c) 
attaching the identifying certificate to the payment infor- 
mation, 

(d) encrypting the payment information with the at- 

35 tached identifying certificate via the encryption program, 
and (e) sending the payment information with the at- 
tached identifying certificate across the network via the 
network routing instructions. A second server connect- 
ed to the network for (f) receiving the encrypted payment 

40 information with the attached identifying certificate, (g) 
decrypting and reading the encrypted payment informa- 
tion with the attached identifying certificate, (h) author- 
izing a payment requested via the payment information, 
and (g) notifying the first server of the authorization. 

45 [001 0] A third particular embodiment described in de- 
tail below is a method for performing a financial trans- 
action. The method includes presenting a customer with 
an amount due in response to a customer's product se- 
lection, accepting a customer's programmable memory 

50 device within a reader portion of a terminal to facilitate 
payment of the amount due, accessing a portion of the 
customer's programmable memory device containing 
payment information. The payment information includes 
at least network address instructions for an issuer of the 

55 customer's programmable memory device, a digital cer- 
tificate for identifying the customer, the customer's fi- 
nancial account information, an encryption program, 
and a customer memo balance containing updated cus- 
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tomer account balances. The customer is identified 
through the digital certificate. A customer's account se- 
lection is received and the a customer's memo balance 
is checked for the selected account to determine if funds 
therein are sufficient to pay the amount due. The pay- 
ment information from the programmable memory de- 
vice is downloaded to a memory portion of the terminal 
and stored for future processing of the financial trans- 
action. The selected product is released to the customer 
and the payment information is uploaded to the issuer 
of the programmable memory device for further 
processing and settlement of the financial transaction. 
[0011] A fourth particular embodiment described in 
detail below is a system for performing a financial trans- 
action. The system includes means for presenting a cus- 
tomer with an amount due in response to a customer's 
product selection, means for accepting a customer's 
programmable memory device within a reader portion 
of a terminal to facilitate payment of the amount due, 
and means for accessing a portion of the customer's 
programmable memory device containing payment in- 
formation. The payment information includes at least 
network address instructions for an issuer of the cus- 
tomer's programmable memory device, a digital certifi- 
cate for identifying the customer, the customer's finan- 
cial account information, an encryption program, and a 
customer memo balance containing updated customer 
account balances. The system also includes means for 
identifying the customer through the digital certificate, 
means for receiving a customer's account selection, 
means for checking a customer's memo balance for the 
selected account to determine if funds therein are suffi- 
cient to pay the amount due, means for downloading the 
payment information from the programmable memory 
device to a memory portion of the terminal, means for 
storing the payment information from the programmable 
memory device in a memory portion of the terminal for 
future processing of the financial transaction, means for 
releasing the selected product to the customer, and 
means for uploading the payment information to the is- 
suer of the programmable memory device for further 
processing and settlement of the financial transaction. 
[0012] A fifth particular embodiment described in de- 
tail below is a system for facilitating a financial transac- 
tion. The system includes a programmable memory de- 
vice issued to a user. The programmable memory de- 
vice includes (a) at least one processor, (b) a digital cer- 
tificate for identifying the user,(c) the user's financial ac- 
count information, (d) network addressing instructions 
for at least the issuer of the programmable memory de- 
vice, and (e) an encryption program for encrypting at 
least (b) and (c). The system also includes a terminal 
for reading information from the programmable memory 
device to facilitate a payment from at least one of a us- 
er's financial accounts and a server for receiving infor- 
mation from the terminal read from the programmable 
memory device and authorizing payment from at least 
one of the user's financial accounts. 



Brief Description of the Drawings 

[0013] In the drawings: 

5 FIG. 1 is a block diagram of a most basic application 
of the invention. 

FIG(s). 2a-2b are diagrams of a smart card used in 
practicing the invention. 

FIG. 3 is a diagram of the electronic memory of a 
10 smart card used in practicing the invention. 

FIG. 4 is a block diagram of a first specific example 
of the invention. 

FIG. 5 is a block diagram of the system used in prac- 
ticing the invention. 
15 FIG. 6 is a block diagram of a second specific ex- 
ample of the invention. 

FIG(s) 7a-7d are diagrams of terminals used in 
practicing the invention. 

20 Detailed Description of the Preferred Embodiments 

[0014] Generally, in the preferred embodiments of the 
present invention as seen in FIG. 1, a customer requests 
a certificate from a service provider (SP) S(A), that is 

25 embodied in a piece of hardware, such as a smart card 
(discussed below). The SP may be the customer's own 
financial institution (e.g., bank) or it may be subscribed 
to by the customer's third party financial institution. The 
certificate is used by the customer when away from his 

30 financial institution, to identify himself to the financial in- 
stitution when he is making a purchase at a compatible 
terminal S(B). Consequently, the certificate represents 
identifying information about the customer. In particular, 
the identifying information represents the financial rela- 

35 tionship between the SP and the customer in the case 
where the SP is also the holder of the customer's ac- 
counts. Alternatively, the certificate may represent iden- 
tifying information about the financial relationship be- 
tween a third-party financial institution and the customer 

40 and the payment preferences of the customer. 

[0015] Further, in the preferred embodiments, when 
the customer attempts to use the certificate on his smart 
card, all relevant purchase information is sent directly to 
the SP for authentication, with little or no actual mer- 

45 chant intervention S(C). Depending on the terminal be- 
ing used, all merchant information is generally added 
automatically, without the need for the merchant to in- 
tervene. This is accomplished via a software program 
within the terminal. Alternatively, the merchant informa- 

50 tion may already be part of the payment vehicle at the 
time the customer adds his/her payment information as 
in the case of, for example, a web-based transaction. 
Once the SP authenticates and authorizes the informa- 
tion, a message regarding the authentication/authoriza- 

55 tion is transmitted to the merchant, allowing the mer- 
chant to proceed or cancel the transaction S(D). If au- 
thentication and authorization are positive, the mer- 
chant releases the goods and/or services to the custom- 
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er, without delay S(E). 
[0016] The smart cards of today have larger memo- 
ries (ejj. . ROM, RAM, EEPROM, Flash), as well as con- 
stantly increasing and improving processing power, 
making them ideal pieces of hardware to be used for 5 
network-type transactions. In FIG(s). 2a-2b, the smart 
card 1 0 contemplated by the present invention holds the 
certificates 26 (discussed below) issued by the SP. In 
the preferred embodiments these certificates 26 may be 
stored in any appropriate electronic memory 23, prefer- 
ably a non-volatile reprogrammable memory such as, 
EEPROM or Flash, within the electronic chip 20 within 
the smart card 10 as well as in an optical memory 15 
and/or a magnetic memory 17, should these be availa- 
ble on the smart card 10. Further, the electronic memory 
23 is capable of storing other large files/programs 24 
such as biometric identifying information 36, a digital 
signature generation program 30, and memo balances 
38 as well as the on-card generated encryption keys 28 
used to encrypt any or all of these files for security. The 
memo balances 38 may represent multiple transactions 
for multiple accounts tracked by the smart card. Review 
of these memo balances 38 prior to making a purchase 
or transferring value allows the customer to make an in- 
formed decision regarding which account to use in 
which situation. Of particular importance for a number 
of the preferred embodiments described below, is the 
capability of the smart card 10 to retain in at least one 
of its multiple memories, particular dialing numbers (e. 
(j., phone numbers) 32 or Internet Universal Resource 
Locators (URLs) 34 in order to enable direct contact with 
the SP on-line, when making purchases over the appro- 
priate networks. The encryption keys are attached via 
the central processing unit (CPU) 22, also located within 
the smart card 10. Once in possession of a certificate 
26, the customer may transfer the certificates 26 onto 
the hard drive of his PC or other appropriate device from 
the memories of the smart card 10, for future retrieval 
without the need for the smart card 10. The certificate 
26 may then be used for identification purposes. 
[0017] Now that the customer is in possession of the 
appropriate hardware, i.e., the smart card, containing all 
relevant customer data, he can make a purchase with 
the smart card over a variety of networks, terminals and 
servers. 

[0018] Referring to FIG. 5, when attempting to make 
a purchase from a participating merchant, the customer 
inserts the smart card into an appropriate reader at a 
POS terminal or through a reader connected to his PC, 
PDA, or a wireless device (e.g., cellular phone, set-top 
box, or similar portable terminal) or he retrieves the cer- 
tificate from his hard drive and sends it to the merchant/ 
customer terminal 54. The certificate is transmitted via 
conventional transmission lines (e.g., telephone or In- 
ternet) or a wireless network 56 to the SP. The SP re- 
ceives the transmitted certificate and other relevant in- 
formation through a specified server 58. After decrypt- 
ing, authenticating and authorizing the certificate and at- 
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tached information, the SP sends results (e.g. , promise 
to pay or denial of payment) to the merchant via any of 
a number of conventional transmission lines or networks 
64. The merchant may receive and read the results via 
its* server 66 and if necessary, transmit notification of 
goods being shipped or delivered or in the case of In- 
ternet services, provide the service to the customer via 
the Internet 67. The merchant is able to read the results 
sent by the SP with the use of the SP's public key. If 
necessary, the SP utilizes the Internet or other appro- 
priate line of communication 60, to interact with the cus- 
tomer's third party financial institution. The third party 
financial institution has an appropriate receiver/trans- 
mission network and server 62 for handling the incoming 
communications from the SP 58. Similarly, the SP uses 
the automated clearing house (ACH) lines 68 to transmit 
and receive clearing and settlement communications to 
and from the merchant's financial institution 70. The 
merchant's financial institution is equipped with a server 
that is capable of receiving and transmitting information 
along at least the ACH lines 68. 
[0019] The following represent specific procedural 
and systematic examples embodying the preferred em- 
bodiment of the present invention. 
[0020] Referring to FIG. 4, in a first specific example, 
a customer obtains a smart card encrypted with a cer- 
tificate from the SP, S1 and attempts to make a purchase 
at a POS merchant terminal. By way of example, the 
customer's smart card contains an identification certifi- 
cate which includes the SP's digital signature that is se- 
cured on a first-level by encryption via public key cryp- 
tography (PKC) and is further secured on a second-level 
by a PIN lock. If necessary, a smart card could be pro- 
grammed to individually lock any number of applications 
within the smart card with a PIN. The smart card itself 
may be secured by a PIN lock and/or biometric lock, 
adding a third and possibly, fourth level of security. The 
smart card could be programmed to require biometric 
authentication only when the customer attempts to 
make a purchase for value exceeding a set amount, for 
example $1,000. Additionally, the smart card contains 
the dialing number and URL for the SP, a menu for se- 
lecting which account he wishes to debit, and memo bal- 
ances for informing the customer or merchant of the val- 
ue amounts in each of his available accounts. 
[0021] The merchant subscribes to the certificate- 
based open payment transaction system and has load- 
ed the appropriate software and/or hardware into the 
POS terminal. This software is not complicated and in 
most cases need only consist of a file containing the 
public keys of the SP so as to be capable of decrypting, 
authenticating, and authorizing messages received 
from the SP under a PKC security system. The POS ter- 
minal may be fixed or stationary, as in the case where 
it is located at an actual retail location or it may be port- 
able, as in the case where merchants are selling con- 
cessions at say, a sporting event. Further, the POS ter- 
minal may be currently on-line or off-line. 
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[0022] When the customer attempts to pay through a 
stationary, on-line terminal using his smart card, the 
merchant requests payment and the customer inserts 
his smart card into the smart card reader portion of the 
merchant terminal S2. The reader recognizes the certif- 5 
icate and other purchase facilitating data in the memory 
or memories of the smart card. If the purchase price ex- 
ceeds $1,000, biometric authentication is required and 
the customer will be asked to provide such information, 
e.g., a fingerprint S3-S5. Similarly, once the biometric 
authentication has been performed, if in addition there 
is a PIN lock on the smart card as in this specific exam- 
ple, the customer is prompted or requested to enter such 
information through, for example, a graphical user inter- 
face (GUI) S7-S8. If either the biometric or PIN authen- 
tication fail, the smart card may allow a limited number 
of subsequent tries and then will terminate the transac- 
tion if no positive authentication is received S6. Further, 
the smart card may lock the card if the number of at- 
tempts to access the card exceeds a predetermined 
number. 

[0023] Once the smart card is accessed, the customer 
decides which account he wishes to use for the pur- 
chase S9. By way of the GUI, the customer is able to 
review the memo balance file to aid in the selection of 
an account to be debited. Further, for an added level of 
security, the representations of individual accounts such 
as MasterCard™, Visa™, and Diners Club™, or various 
checking and savings accounts shown to the customer, 
need not represent the actual account numbers for 
these payment vehicles. Instead, the representations 
are only account identifiers and are only readable by the 
holder of the customer's respective accounts. Whether 
the account holder is the SP or a third party financial 
institution is irrelevant at this stage. One advantage of 
having the same financial institution holding each of the 
accounts of the customer is that it is possible for the cus- 
tomer to split up the payment for a particularly large pur- 
chase and utilize more than one account for the same 
payment. In certain of the specific examples, the mer- 
chant never sees the selected payment method and this 
is not his concern since he is assured through the digital 
signatures attached to the authorizations from the SP 
that he will receive payment for the full amount. The 
method contemplated by the invention allows this to oc- 
cur without any interaction from the merchant and of 
course, since there is no need to pay a merchant acquir- 
er to sort and send the payment requests, there are no 
added transaction costs. 

[0024] After the customer has selected his method of 
payment and has signed the certificate with his private 
key, the merchant proceeds to add additional transac- 
tion data, pertaining to his payment needs to the certif- 
icate prior to sending it to the SP S10. This additional 
data may include the merchants financial institution 
routing number as well as the merchant's deposit ac- 
count number and the merchant's encrypted digital sig- 
nature for identification by the SP. Alternatively, the mer- 



chant's information is already attached to a payment ve- 
hicle prior to the customer adding his/her information as 
in the case of a web-based transaction. 
[0025] When the merchant has completed the addi- 
tion of his data and digitally signed the certificate, the 
dialing number or URL on the smart card, dials up the 
SP and transmits all of the certificate information thereto 
S11. Upon receiving the certificate, the SP will decrypt 
and authenticate the merchant's ID signature as well as 
the customer's ID information and authorize the custom- 
er's certificate in light of the purchase information S12. 
Authorization involves comparing the balance of the 
customer's requested account with the requested pay- 
ment amount, in the case where the SP is also the holder 
of the customer's accounts S13-S14. Where the SP is 
not the holder of the customer's accounts, the SP uses 
the third party financial institutions dialing number or 
URL, which is found in the smart card and sent with the 
certificate from the POS terminal, to access the custom- 
er's third party financial institution and obtain authoriza- 
tion to proceed with the transaction S13, S15. 
[0026] Upon obtaining authorization from the third 
party financial institution or based on its own authoriza- 
tion process, the SP will send a digitally signed response 
to the merchant, indicating the result of the comparison 
S16. If the SP approves the purchase, prior to debiting 
the account of the customer and causing the payment 
to be deposited into the merchants deposit account, it 
will await a digitally signed confirmation from the mer- 
chant (if desired) and will proceed with the clearing and 
settlement procedures S18. Either upon receiving the 
signed authorization from the SP or upon sending their 
digital confirmation, the merchant will release the pur- 
chased goods to the customer, knowing that the pay- 
ment will be deposited into their account by the SP S17. 
This release of goods may be, inter alia, electronic as 
in the case of Internet services, shipped in the case of 
tangible products, or the products may be released di- 
rectly to the customer in the case of a POS transaction. 
Finally, the SP will pay the merchant and post the debit 
to the customer's account either with the SP or with the 
third party financial institution S19. The payment and 
posting steps may be accomplished through the tradi- 
tional automated clearing house (ACH) channels. 
[0027] This same procedure may be followed using a 
portable POS terminal. The difference being that the 
portable terminal may not necessarily, and in all likeli- 
hood, is unable to take advantage of the traditional hard- 
wire networks, such as the telephone lines. Instead, ac- 
cess to the SP may occur through a wireless connection 
(e.g., cordless operating at, inter alia, 900 megahertz 
and 2.4 gigahertz or cellular operating at approved fre- 
quencies). The portable POS terminal may be powered 
by a standard ac power supply from a conventional out- 
let or for truly mobile terminals, by a rechargeable bat- 
tery. In order to cause the connection between the port- 
able device and the SP, various local area networks 
(LANs), wide area networks (WANs) and cellular net- 
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works may be employed. Specific examples of wireless 
transaction procedures and systems are more fully de- 
scribed in Patent No. 5,796,832 entitled WIRELESS 
TRANSACTION AND INFORMATION SYSTEM which 
is commonly assigned and is hereby incorporated by 5 
reference. 

[0028] In a second specific example, the POS termi- 
nal is either stationary or portable but is not "on-line" in 
the traditional sense, such that it is connected to the SP 
during the transaction with the customer. Instead of us- 
ing the SP to authenticate the information stored in the 
customer's certificate(s), the merchant does his own off- 
line authentication. 

[0029] Referring to FIG. 6, after the customer inserts 
his smart card containing a certificate into an off-line 
merchant terminal S2, the merchant uses a security ac- 
cess module (SAM) in order to decrypt the secure cer- 
tificates and access the information on the customer's 
smart card S20. The customer then selects which ac- 
count he wishes to use in the transaction S21 and if nec- 
essary, the merchant is able to view the memo balances 
and determine the availability of funds within the cus- 
tomer's chosen account S22-S24. Once a viable ac- 
count has been selected, the merchant releases the pur- 
chased goods and/or services to the customer S25. 
[0030] Optionally, the merchant may utilize his own 
terminal and smart card for storing these off-line trans- 
actions, an audit copy of the transactions, his own iden- 
tification certificates containing, for example, merchant 
digital signatures, and dialing numbers and URLs for ap- 
propriate financial institutions and/or SPs S26. The mer- 
chant may store the transactions from, for example, a 
single day, in aggregate or summarized form on his 
smart card, and in transaction specific form in the mer- 
chant terminal memory. At a time convenient for the 
merchant, the merchant goes on-line (e.g. , direct dial or 
Internet) and utilizes his smart card and/or terminal to 
up-load batches of transactions to the SPs S27. Once 
the batch of transactions is received by the SP and proc- 
essed, the SP returns a completion message, allowing 
the merchant to purge the stored information from the 
smart card and the merchant terminal S28. The SP then 
may proceed with the clearing and settlement proce- 
dures S29. 

[0031 ] In a third specific example, a customer access- 
es a merchant website or webpage via his PC. The cus- 
tomer decides to purchase an item and is directed via 
the webpage to enter appropriate purchasing data. The 
customer inserts his SP issued smart card, containing 
the information certificates into a smart card reader 
plug-in attached to his PC. If the merchant is a partici- 
pant in the certificate-based open payment transaction 
system, the merchant bank's routing number and the ac- 
count therein which the merchant wishes to have cred- 
ited, will automatically be added to the purchasing data 
entered by the customer. The customer proceeds to en- 
ter the purchasing information into the webpage order 
form, selecting the appropriate method of payment, e. 



g., credit or debit, and purchase price. When the order 
form is complete, the customer digitally signs the pur- 
chasing information with his private key and attaches 
the certificate from the smart card to the purchasing in- 
formation and executes the transmit step (e.g., selecting 
"send"), resulting in the form being sent over the network 
to the SP. The SP authorizes the customer's purchase, 
either through a comparison with its' own account 
records or by contacting the third party financial institu- 
tion holding the customer's accounts and receiving au- 
thorization. The SP digitally signs the order and sends 
it to the merchant, who decrypts the SP's signature and 
sends confirmation back to the SP and the customer, 
attaching the merchant's digital signature. The SP pro- 
ceeds to pay the merchant and post the debit to the cus- 
tomer's chosen account and generally institute clearing 
and settlement procedures. 

[0032] In a fourth specific example, a customer uses 
his SP issued smart card to make a purchase through 
a telephone, either conventional or wireless, where the 
telephone is equipped with a smart card reader. In this 
case, the conventional alphanumeric keypad may be 
used to enter data or verbal data may be entered where 
an appropriate voice response unit (VRU) and/or voice 
recognition unit is available. The entrance of the pur- 
chase data through either the keypad or vocally, com- 
bined with the electronic data from the smart card, al- 
lows the customer to make purchases with virtually the 
same ease as if he were sitting at his PC and filling in a 
webpage or standing at a POS terminal providing infor- 
mation through a keypad or touchscreen. 
[0033] To further facilitate a wireless or cellular em- 
bodiment of the fourth specific example, the certificate 
issued by the service provider may include multiple 
types of identifiers, for use with the server of the service 
provider as well as the customer's third party financial 
institution. For example, the certificate might include a 
first identification number, used by the service provider 
to identify the individual, and a second identification 
number, such as an encrypted PIN, for use with the cus- 
tomer's third party financial institution during the author- 
ization process. In the situation where the SP does not 
actually hold the accounts of the customer and thus can 
not actually authorize a transaction, the SP can use the 
encrypted PIN found in the certificate to access the third 
party financial institution over the conventional authori- 
zation channels, such as the ATM lines. The encrypted 
PIN is part of the certificate issued by the SP to the third 
party financial institution's customer on behalf of the 
third party financial institution. All of this identifying in- 
formation and transaction facilitating information is se- 
cure since it is part of the encrypted message identified 
by the certificate, readable only by the SP who holds the 
matching public key. Further, if the card itself is PIN- 
iocked or biometrically locked, there is an added level 
of security. 

[0034] In each of the specific examples described 
above, there is a public-private key security feature in 
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place that protects the important financial information of 
both the customer and the merchant. The system allows 
each of the involved parties, e.g. , customer, merchant, 
SP, third party financial institution, to utilize public keys 
to decrypt digital signatures for ID authentication. By us- 5 
ing representative account identifiers instead of the ac- 
tual account numbers or by routing the customers infor- 
mation through the SP, without ever needing to pass it 
through the merchant, the information remains within 
the knowledge of only a limited number of parties. 
[0035] There are multiple levels of security realizable 
using the methods and systems of the current embodi- 
ments. Depending upon the security needs of the cus- 
tomer, in an embodiment of the present invention, the 
customer generates his/her own key pair off of the is- 
sued smart card, instead of receiving the generated 
keys with the smart card. In this embodiment, the SP 
issues the smart card to the customer having a standard 
PIN thereon for unlocking the card, but the encryption 
key pairs and the certificate have yet to be generated. 
When the customer receives the card and unlocks the 
card with the PIN, using the software supplied by the SP 
the customer is able to generate his/her own key pair 
and a profile to be encrypted with a digital signature 
based on the private key and forwarded to the SP along 
with the attached public key for formation of a service 
provider-backed certificate. A profile contains informa- 
tion such as name, address, social security number, 
birthdate, etc. This customer-key generation embodi- 
ment limits the number of entities who are privy to the 
both the public and private key and consequently this 
embodiment provides the maximum amount of security. 
In an alternative embodiment, the key pair is generated 
by the SP and provided with the customer profile based 
certificate loaded onto the smart card. 
[0036] Since the issue of security is of utmost impor- 
tance when transmitting personal financial information 
over public or quasi-public networks, it is optionally pos- 
sible to have the SP issue a certified smart card, having, 
in addition to the electronic memory, a magnetic mem- 
ory wherein, there is a one-time use amount of credit or 
debit attached thereto. A description of a multi-technol- 
ogy smart card may be found in the commonly assigned 
co-pending application serial number 09/274,462 enti- 
tled "METHOD AND SYSTEM FOR REMOTE BANK- 
ING WITH A MULTI-MEMORY TECHNOLOGY SMART 
CARD" filed March 22, 1999. If this option is selected 
by the customer, they can instruct the SP to put into the 
magnetic memory of the smart card, an amount of credit 
related to say, the customer's MasterCard™ account 
held by the SP or a customer's third party financial in- 
stitution. Further, the smart card may be programmed 
to automatically erase the particular track of the mag- 
netic memory which housed the credit information, after 
it has been selected by the customer for use in a pur- 
chasing transaction. Consequently, there is limited risk 
that someone could tap into the network or that a trusted 
party could misuse this erasable information since the 



smart card does not allow for repeat uses of the infor- 
mation, once it has been transmitted into a network. 
[0037] In order to facilitate the reading of the electron- 
ic memory and the magnetic memory for purposes of 
the one-time use feature or in some instances and the 
reading of an optical memory housed on the smart card, 
the customer and/or merchant will require various types 
of readers. In commonly assigned, co-pending applica- 
tion serial number 09/271 ,206 filed March 1 7, 1 999 en- 
titled "IMPROVED APPARATUS AND SYSTEM FOR 
OPTICAL CARD READING AND METHOD OF USE," 
there is described a read/write device that allows for the 
reading of information off of any one of an optical, elec- 
tronic, and magnetic memory found on a single smart 
card and is hereby incorporated by reference. Further, 
there are currently available, magnetic memory reader 
plug-ins, to be used in conjunction with a PC, PDA, set- 
top box or other terminal, having the appropriate com- 
patible port. 

[0038] Referring to FIG(s). 7a-7d, various terminals 
which may be used in practicing the invention are illus- 
trated. FIG. 7a is a cellular phone 72 having thereon a 
display/output component 82 for viewing information 
that is retrieved from the smart card 10 and a keypad/ 
input component 73 for entering information. The cellu- 
lar phone 72 may be used for wireless transactions. In 
order to read information from the smart card 10, there 
is a smart card reader plug-in 74 that is compatible with, 
for example, the docking port 71 of the cellular phone 
72. It should be noted at this point that for each of the 
terminals shown in FIG(s). 7a-7d, the smart card reader 
may be either a compatible plug-in component for use 
with an existing port or the reader may be an internal 
component of the terminal. 

[0039] FIG. 7b illustrates a generic POS terminal 76 
which may be used for either off-line or on-line transac- 
tions. As with the cellular phone 72, the POS terminal 
76 has a display/output component 82 and a keypad/ 
input component 73. Further, in this example, the POS 
terminal 76 has both a swipe reader component 80 and 
an internal smart card reader 78. When used on-line, an 
Internet or telephone connection may be provided 
through an appropriate cable 81 . 
[0040] FIG. 7c illustrates a PC 86 which is connected 
to the Internet via cable 81 such that a user may browse 
through merchant websites via the display 82. The PC 
86 is compatible with a smart card reader plug-in 74 (or 
alternately, as discussed above, the PC could have a 
separate internal device for reading smart cards). After 
inserting the smart card 1 0 into the appropriate reader, 
the input/keyboard component 73 or a conventional 
mouse 75, may be used to provide transaction data to 
an order form on the website and to send the information 
to the SP. 

[0041] Finally, in FIG. 7d, a generic PDA 90 is illus- 
trated, having a display/output component 82 and an in- 
put/keypad component 73, in addition to a smart card 
reader plug-in 74 for use with smart card 10. 
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1 . A method for facilitating a financial transaction over 
a first network comprising: 
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issuing a programmable memory device to a 
first user, wherein the programmable memory 
device contains at least the following for formu- 
lating payment instructions network address in- 
structions for an issuer of the programmable 
memory device, a first user's digital certificate, 
a first user's financial account information, and 
an encryption program; 
issuing software to a second user, wherein the 
software includes payment information of the 
second user including a second user's financial 
account information and further wherein the 
software is capable of interacting with the pro- 
grammable memory device over the first net- 
work; 

forming a connection between the programma- 
ble memory device and the software; 
receiving across the connection the payment 
instructions; 

adding the second user's payment information 
to the payment instructions; 
routing the payment information and the pay- 
ment instructions to the issuer utilizing the net- 
work address instructions; and 
receiving the payment information and the pay- 
ment instructions, wherein the issuer is capable 
of accessing at least one of the first user's fi- 
nancial account information and a second us- 
er's financial account information. 

The method according to claim 1 , wherein the pay- 
ment information of the second user further in- 
cludes a second user's digital certificate. 



15 

[0042] Further, the examples above limit the 
of necessary parties as well as the number of transac- 
tions that are the responsibility of each of the interacting 
parties. The invention allows the merchant to disregard 
entirely the choice of payment method by the customer 
since the customer's accounts are each certified by the 
SP. There is no need for the merchant to hire a merchant 
acquirer to sort through numerous transactions and con- 
tact the appropriate credit card verification line for each 
transaction. In fact, the invention does not require use 
of the conventional credit transaction network at all. The 
SP or the SP via the customer's third party financial in- 
stitution, does all of the authenticating, authorizing, 
crediting and debiting. The merchant need only acquire 
the SP's public key. In the case of non payment, the mer- 
chant has recourse due to the SP signed transaction. 
[0043] The relationship between the SP and a cus- 
tomer's third party financial institution may take on var- 
ious levels of interaction. On a first level, the SP issues 
the certificates to the customer on behalf of the third par- 
ty financial institution. These certificates include dialing 
numbers or URLs for not only the SP, but the third party 
financial institution as well. When the relationship be- 
tween the SP and the third party financial institution is 
on a first level, the SP receives the initial certificate for 
authentication and authorization from the customer 
making a purchase request but, the SP only does the 
ID authentication. The authorization is performed by the 
third party financial institution via the dialing number or 
URL that was part of the originally issued certificate. In 
this case, the SP and third party financial institution have 
the appropriate keys for allowing digital signature and 
decryption between the two. Once the SP receives au- 
thorization from the third party financial institution, the 
SP sends the results to the merchant who proceeds with 
the transaction as discussed in the specific examples 
above. 

[0044] If a second level relationship has been estab- 
lished between the SP and the customer's third party 
financial institution, the SP proceeds to do both the ID 
authentication as well as the authorization, without first 
consulting the third party financial institution. The SP 
may settle with the third party financial institution at 
some later time but, the nature of a second level rela- 
tionship is that the SP is authorized and indemnified by 
the third party financial institution in proceeding with 
transaction authorization based on the customer's ac- 
count information garnered from the smart card certifi- 
cate. 

[0045] The examples described above are merely 
representative of the applications contemplated by the 
inventors. One skilled in the art is aware of the many 
alternate embodiments that are within the scope of the 
invention. 



40 3. The method according to claim 1 , wherein the first 
network is the Internet. 

4. The method according to claim 1 , wherein the first 
network is a wireless network. 

45 

5. The method according to claim 1 , wherein the net- 
work address instructions include at least one of a 
universal resource locator and a phone number. 

50 6. The method according to claim 1 , further including 
authorizing a payment amount read from the pay- 
ment instructions. 

7. The method according to claim 6, wherein author- 
55 izing a payment amount includes requesting via a 
second network authorization from a first user's fi- 
nancial institution that maintains the first user's fi- 
nancial account information. 
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8. The method according to claim 7, wherein the pay- 
ment instructions further include an encrypted per- 
sonal identification number recognizable by the first 
user's financial institution for accessing the first us- 
er's financial account information. 

9. The method according to claim 7, wherein the sec- 
ond network is an ATM network. 

10. The method according to claim 7, wherein the sec- 
ond network is the Internet. 

11. The method according to claim 1 , wherein the pro- 
grammable memory device is a smart card. 

12. The method according to claim 1, wherein the first 
user's financial account information includes the 
first user's account identifier. 

13. The method according to claim 1 3, wherein the first 
user's account identifier includes at least one of an 
account type and an account number. 

14. The method according to claim 1 , wherein the first 
user's financial account information includes the 
first user's financial institution routing number. 

15. The method according to claim 1, wherein the en- 
cryption program contains a private key generated 
by the issuer. 

16. The method according to claim 1, wherein the en- 
cryption program generates a private/public key 
pair within the programmable memory device. 

17. The method according to claim 1, wherein the sec- 
ond user's financial account information includes 
the first user's account identifier. 

18. The method according to claim 17, wherein the sec- 
ond user's account identifier includes at least one 
of an account type and an account number. 

19. The method according to claim 1, wherein the sec- 
ond user's financial account information includes 
the second user's financial institution routing 
number. 

20. A system for facilitating financial transactions over 
a network comprising: 

a programmable memory device including at 
least an identifying certificate, payment infor- 
mation, network routing instructions and an en- 
cryption program; 

a first server for offering at least one product via 

the network through a terminal; 

a processor connected to the terminal for 



(a) accessing the programmable memory 
device, 

(b) retrieving the identifying certificate, the 
payment information, the network routing 

5 instructions and the encryption program off 

of the programmable memory device, 

(c) attaching the identifying certificate to 
the payment information, 

(d) encrypting the payment information 
10 with the attached identifying certificate via 

the encryption program, and 

(e) sending the payment information with 
the attached identifying certificate across 
the network via the network routing instruc- 
ts tions, and 

a second server connected to the network for 

(f) receiving the encrypted payment infor- 
20 mation with the attached identifying certifi- 
cate, 

(g) decrypting and reading the encrypted 
payment information with the attached 
identifying certificate, 

25 (h) authorizing a payment requested via 

the payment information, and 
(i) notifying the first server of the authoriza- 
tion. 

30 21. A system according to claim 20, wherein the termi- 
nal is wireless. 



22. A method for performing a financial transaction 
comprising: 

presenting a customer with an amount due in 
response to a customer's product selection; 
accepting a customer's programmable memory 
device within a reader portion of a terminal to 
facilitate payment of the amount due; 
accessing a portion of the customer's program- 
mable memory device containing payment in- 
formation, wherein the payment information in- 
cludes at least network address instructions for 
an issuer of the customer's programmable 
memory device, a digital certificate for identify- 
ing the customer, the customer's financial ac- 
count information, an encryption program, and 
a customer memo balance containing updated 
customer account balances; 
identifying the customer through the digital cer- 
tificate; 

receiving a customer's account selection; 
checking a customer's memo balance for the 
selected account to determine if funds therein 
are sufficient to pay the amount due; 
downloading the payment information from the 
programmable memory device to a memory 
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portion of the terminal; 
storing the payment information from the pro- 
grammable memory device in a memory por- 
tion of the terminal for future processing of the 
financial transaction; 5 
releasing the selected product to the customer; 
uploading the payment information to the issuer 
of the programmable memory device for further 
processing and settlement of the financial 
transaction. 10 

23. The method according to claim 22, wherein the ter- 
minal is wireless. 

24. The method according to claim 22, further compris- *5 
ing: 

receiving verification from the issuer of the pro- 
grammable memory device that the financial 
transaction is authorized; and 20 
updating a merchant transaction log in the 
memory portion of the terminal to reflect author- 
ization of the financial transaction by the issuer 
of the programmable memory device. 

25 

25. A system for performing a financial transaction 
comprising: 

means for presenting a customer with an 
amount due in response to a customer's prod- 30 
uct selection; 

means for accepting a customer's programma- 
ble memory device within a reader portion of a 
terminal to facilitate payment of the amount 
due; 35 
means for accessing a portion of the custom- 
er's programmable memory device containing 
payment information, wherein the payment in- 
formation includes at least network address in- 
structions for an issuer of the customer's pro- *o 
grammable memory device, a digital certificate 
for identifying the customer, the customer's fi- 
nancial account information, an encryption pro- 
gram, and a customer memo balance contain- 
ing updated customer account balances; 45 
means for identifying the customer through the 
digital certificate; 

means for receiving a customer's account se- 
lection; 

means for checking a customer's memo bal- 50 
ance for the selected account to determine if 
funds therein are sufficient to pay the amount 
due; 

means for downloading the payment informa- 
tion from the programmable memory device to 55 
a memory portion of the terminal; 
means for storing the payment information from 
the programmable memory device in a memory 



20 

portion of the terminal for future processing of 
the financial transaction; 
means for releasing the selected product to the 
customer; 

means for uploading the payment information 
to the issuer of the programmable memory de- 
vice for further processing and settlement of the 
financial transaction. 

26. The system according to claim 25, wherein the ter- 
minal is wireless. 

27. The system according to claim 25, further compris- 
ing: 

means for receiving verification from the issuer 
of the programmable memory device that the 
financial transaction is authorized; and 
means for updating a merchant transaction log 
in the memory portion of the terminal to reflect 
authorization of the financial transaction by the 
issuer of the programmable memory device. 

28. A system for facilitating a financial transaction com- 
prising: 

a programmable memory device issued to a us- 
er including 

(a) at least one processor; 

(b) a digital certificate for identifying the us- 
er; 

(c) the user's financial account information; 

(d) network addressing instructions for at 
least the issuer of the programmable mem- 
ory device; and 

(e) an encryption program for encrypting at 
least (b) and (c); 

a terminal for reading information from the pro- 
grammable memory device to facilitate a pay- 
ment from at least one of a user's financial ac- 
counts; 

a server for receiving information from the ter- 
minal read from the programmable memory de- 
vice and authorizing payment from at least one 
of the user's financial accounts. 
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